As the Internet has evolved there has been an increased need for communication between applications over a network. Extensible Markup Language (XML) was developed as a flexible way to create common information formats and share both the format and the data between applications. As opposed to Hypertext Markup Language (HTML), which is designed specifically for web browsers, XML is designed for much wider use and is extensible to fit each application.
XML has been widely used for representing application specific data structures, for example in web services. A web service is, for instance, a set of related application functions that can be programmatically invoked over the Internet. Businesses can dynamically mix and match web services to perform complex tasks.
The XML format can be used to facilitate the use of the web service by a remote service requester. Web Services Description Language (WSDL) is an XML-based language for describing web services and how to access them. The service requester can interact with the web service in a manner prescribed by the web service's WSDL description using Simple Object Access Protocol (SOAP) messages, typically conveyed using Hypertext Transfer Protocol (HTTP).
FIG. 1 shows a simplified diagram of the use of a web service 103 by a service requester machine 104. Web services are typically application programming interfaces (API) or web APIs that are accessed via HTTP and executed on a remote system hosting the requested services. World Wide Web Consortium (W3C) defines a web service as a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format, such as WSDL. Other systems interact with the web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.
As illustrated in FIG. 1, a service provider machine 102 hosts the web service 103 and makes it accessible using protocols such as SOAP. Web service 103 is described by a WSDL document 101 that may be stored on the provider's server. Web service 103 is published to a service broker 100, such as a Universal Description, Discovery, and Integration (UDDI) service broker. Service broker 100 acts like a phone book with a web service name and a pointer back to WSDL 101.
For service requester 104 to use the remote web service 103, service requester 104 looks up the web service 103 via the phone book (i.e., UDDI service broker 100). More particularly, the service requester machine 104 may host the service request 105. Service requester 104 discovers web service 103 via the UDDI service broker 100. Service broker 100, which has a pointer to the web service's WSDL 101, passes this pointer on to service requester 104, so that service requester 104 can format its SOAP message correctly. Service requester 104 then sends its request to web service 103 using a SOAP message and receives a SOAP response satisfying the request from web service 103.
It should be noted that FIG. 1 is greatly simplified in that many interoperability assumptions are made between service requester machine 104 and server provider machine 102. In practice, a number of platform providers, independent software vendors, and utility software developers have implemented web services protocols (e.g., SOAP and WSDL) in their products. However, ambiguities and the large number of choices in implementation specifics have led to differing interpretations, thereby resulting in incompatible implementations. As a consequence, serious interoperability problems have developed in SOAP-based Web services where one web service implementation may be unable to understand a message from another web service implementation. Thus, there is a need for a technique that enables these differing web service implementations understand the messages exchanged between each other and thereby enabling communication between them.